docker comenzó a arrojar este error:
standard_init_linux.go:178: el proceso de usuario exec provocó un "error de formato exec"
cada vez que ejecuto un contenedor docker específico con CMD o ENTRYPOINT, sin tener en cuenta ningún cambio en el archivo que no sea eliminar CMD o ENTRYPOINT. aquí está el archivo docker con el que he estado trabajando, que funcionó perfectamente hasta hace aproximadamente una hora:
FROM buildpack-deps:jessie ENV PATH /usr/local/bin:$PATH ENV LANG C.UTF-8 RUN apt-get update && apt-get install -y --no-install-recommends \ tcl \ tk \ && rm -rf /var/lib/apt/lists/* ENV GPG_KEY 0D96DF4D4110E5C43FBFB17F2D347EA6AA65421D ENV PYTHON_VERSION 3.6.0 ENV PYTHON_PIP_VERSION 9.0.1 RUN set -ex \ && buildDeps=' \ tcl-dev \ tk-dev \ ' \ && apt-get update && apt-get install -y $buildDeps --no-install-recommends && rm -rf /var/lib/apt/lists/* \ \ && wget -O python.tar.xz "https://www.python.org/ftp/python/${PYTHON_VERSION%%[az]*}/Python-$PYTHON_VERSION.tar.xz" \ && wget -O python.tar.xz.asc "https://www.python.org/ftp/python/${PYTHON_VERSION%%[az]*}/Python-$PYTHON_VERSION.tar.xz.asc" \ && export GNUPGHOME="$(mktemp -d)" \ && gpg --keyserver ha.pool.sks-keyservers.net --recv-keys "$GPG_KEY" \ && gpg --batch --verify python.tar.xz.asc python.tar.xz \ && rm -r "$GNUPGHOME" python.tar.xz.asc \ && mkdir -p /usr/src/python \ && tar -xJC /usr/src/python --strip-components=1 -f python.tar.xz \ && rm python.tar.xz \ \ && cd /usr/src/python \ && ./configure \ --enable-loadable-sqlite-extensions \ --enable-shared \ && make -j$(nproc) \ && make install \ && ldconfig \ \ && if [ ! -e /usr/local/bin/pip3 ]; then : \ && wget -O /tmp/get-pip.py 'https://bootstrap.pypa.io/get-pip.py' \ && python3 /tmp/get-pip.py "pip==$PYTHON_PIP_VERSION" \ && rm /tmp/get-pip.py \ ; fi \ && pip3 install --no-cache-dir --upgrade --force-reinstall "pip==$PYTHON_PIP_VERSION" \ && [ "$(pip list |tac|tac| awk -F '[ ()]+' '$1 == "pip" { print $2; exit }')" = "$PYTHON_PIP_VERSION" ] \ \ && find /usr/local -depth \ \( \ \( -type d -a -name test -o -name tests \) \ -o \ \( -type f -a -name '*.pyc' -o -name '*.pyo' \) \ \) -exec rm -rf '{}' + \ && apt-get purge -y --auto-remove $buildDeps \ && rm -rf /usr/src/python ~/.cache RUN cd /usr/local/bin \ && { [ -e easy_install ] || ln -s easy_install-* easy_install; } \ && ln -s idle3 idle \ && ln -s pydoc3 pydoc \ && ln -s python3 python \ && ln -s python3-config python-config RUN pip install uwsgi RUN mkdir /config RUN mkdir /logs ENV HOME /var/www WORKDIR /config ADD conf/requirements.txt /config RUN pip install -r /config/requirements.txt ADD conf/wsgi.py /config ADD conf/wsgi.ini /config ADD conf/__init__.py /config ADD start.sh /bin/start.sh RUN chmod +x /bin/start.sh EXPOSE 8000 ENTRYPOINT ["start.sh", "uwsgi", "--ini", "wsgi.ini"]me olvidé de poner
#!/bin/bashen la parte superior del archivo sh, problema resuelto.
Me he enfrentado al mismo problema en RHEL 7.3, docker 17.05-ce cuando ejecuto una imagen cargada sin conexión. Parecía que el controlador de almacenamiento predeterminado de RHEL/CentOS cambió de mapeador de dispositivos a superposición. Revertir el controlador a devicemapper solucionó el problema.
dockerd --storage-driver=devicemappero
/etc/docker/daemon.json { "storage-driver": "devicemapper" }Otra posible razón para esto podría ser si el archivo se guarda con finales de línea de Windows (CRLF). Guárdelo con finales de línea Unix (LF) y se encontrará el archivo.
En mi caso, "drené" mi instancia de ECS y los "activé" nuevamente y luego el error desapareció.
Extendiendo a la respuesta aceptada:
Para una imagen alpina (sin bash):
#!/bin/ashen la parte superior del archivo sh, resuelve el problema.
Una posibilidad más es que #!/bin/bash no esté en la primera línea. Realmente no debe haber nada antes (sin líneas vacías, nada).
No es una respuesta directa a la pregunta formulada. Aunque recibí el error al llamar a "docker-compose up" para abrir mi aplicación nodejs. Me di cuenta de que en mi "Dockerfile" tenía CMD ["./server.js"] .
Para solucionarlo, lo reemplacé con CMD ["npm","start"] y eso resolvió el problema. Espero que si alguien aterriza aquí por esta excepción, pueda encontrarlo útil.
Añadir este código
#!/usr/bin/env bashen la parte superior de su archivo de script.
Esto puede suceder si intenta ejecutar una imagen construida x86 en una máquina arm64/aarch64.
Deberá reconstruir la imagen utilizando la arquitectura correspondiente.
Si está utilizando un enrutador IBR1700 que ejecuta contenedores, es posible que obtenga un error similar cuando esté en la línea de comando del enrutador después de usar la container logs test de comando (donde prueba es el nombre del contenedor).
Para solucionar esto, debe compilar la aplicación para que se ejecute en una plataforma diferente. Utiliza linux/arm/v7.
docker run -it --rm --privileged docker/binfmt:a7996909642ee92942dcd6cff44b9b95f08dad64 docker buildx create --name mybuilder docker buildx use mybuilder docker buildx build --platform linux/arm/v7 --no-cache -t <username/repository>:<tag> . --pushEmpujar al repositorio con esta compilación significa que puede ejecutarse en el enrutador.
Obtuve el mismo error, estaba creando una imagen ARM después de cambiar a AMD. Problema solucionado
Ese error generalmente significa que está intentando ejecutar esta imagen amd64 en un host que no es amd64 (como 32 bits o ARM).
INTENTE CONSTRUIR usando buildx y especificando --platform linux/amd64
Comando de muestra
docker buildx build -t ranjithkumarmv/node-12.13.0-awscli . --platform linux/amd64Si la imagen de Docker se crea en un chip M1 y se carga para que Fargate la implemente, notará este error de contenedor en Fargate:
standard_init_linux.go:228: exec user process caused: exec format errorHay un par de formas de evitar esto. Tu también puedes:
docker buildx build --platform=linux/amd64 -t image-name:version . FROM --platform=linux/amd64 BASE_IMAGE:VERSIONTuve un problema similar standard_init_linux.go:228: exec user process caused: exec format error , pero las respuestas no me ayudaron. Finalmente, descubrí que era la versión anterior de docker 17.09.0-ce que también es predeterminada en Circle CI, por lo que justo después de cambiarlo a la versión más reciente, se resolvió el problema.
Para mí, mi clúster ECS era arquitectura arm64, pero mi imagen de docker mostraba arquitectura amd64. Reconstruí mi imagen acoplable: https://docs.docker.com/desktop/multi-arch/
Para aquellos que intentan crear imágenes para arquitecturas aarch64 o armv7l en el sistema Linux amd64 y se encuentran con el mismo error: verifique si qemu-user-static está instalado. De lo contrario, instálelo con sudo apt install qemu-user-static en Ubuntu/Debian/Mint, etc., o con sudo dnf install qemu-user-static en Fedora
Este error también podría ocurrir si una imagen se creó en una MacBook Pro con un M1 Apple Silicon Chip , que está basado en ARM, por lo que, de manera predeterminada, el comando de compilación de Docker apunta a arm64 .
Especificar la plataforma tanto para el comando de compilación como para la etiqueta de versión fue suficiente:
# Build for ARM64 docker build -t <image-name>:<version>-arm64 . # Build for AMD64 docker build --platform=linux/amd64 -t <image-name>:<version>-amd64 .